<html>
<head><meta charset="utf-8"><title>disarming mem::uninitialized · t-libs · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/index.html">t-libs</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html">disarming mem::uninitialized</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="244030355"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244030355" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244030355">(Jun 26 2021 at 19:27)</a>:</h4>
<p>I've been thinking about how mem::uninitialized was not just deprecated, but "deprecated with extreme prejudice", in recognition of the fact that it's impossible to use safely. Now that it's been deprecated for a good while, it occurs to me that this function could be made safe, without technically causing an API change... by replacing its inner call to <code>MaybeUninit::uninit().assume_init()</code> with <code>mem::zeroed()</code>. This would de-fang any remaining uses of mem::uninitialized in the wild and the only effect would be performance-related. (With shades of the apocryphal tale of the library that once deprecated an API by inserting successively larger <code>sleep()</code> calls in every release.)</p>



<a name="244030410"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244030410" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244030410">(Jun 26 2021 at 19:28)</a>:</h4>
<p>zero-byte bit pattern is not always a valid pattern for a type to have.</p>



<a name="244030416"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244030416" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244030416">(Jun 26 2021 at 19:28)</a>:</h4>
<p>both mem::uninitialized and mem::zeroed are already guaranteed to panic if the type contains invalid bit representations</p>



<a name="244030419"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244030419" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244030419">(Jun 26 2021 at 19:29)</a>:</h4>
<p>Oh, nice.</p>



<a name="244030432"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244030432" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244030432">(Jun 26 2021 at 19:29)</a>:</h4>
<p>I remember that now, it was a recent change too, I remember people complaining about the change not being backwards compatible ^^</p>



<a name="244030601"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244030601" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244030601">(Jun 26 2021 at 19:33)</a>:</h4>
<p>Could this lead to an OOM when zeroing a large amount of memory where unitialized wouldn't?</p>



<a name="244030643"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244030643" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244030643">(Jun 26 2021 at 19:34)</a>:</h4>
<p>presumably the program would attempt to actually initialize that memory at some point before proceeding, thus hitting the same OOM, yes?</p>



<a name="244030866"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244030866" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244030866">(Jun 26 2021 at 19:39)</a>:</h4>
<p>Not if they're using sparse arrays for some reason</p>



<a name="244031133"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244031133" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244031133">(Jun 26 2021 at 19:45)</a>:</h4>
<p>if you have a contiguous block of uninitialized array elements and then try to access the last element in the array, wouldn't that trigger a reservation for the entire block and cause the OOM?</p>



<a name="244031215"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244031215" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244031215">(Jun 26 2021 at 19:47)</a>:</h4>
<p>or not even the last element, any element at all?</p>



<a name="244031228"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244031228" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244031228">(Jun 26 2021 at 19:47)</a>:</h4>
<p>On linux, at least, the memory is materialized on a per-page basis.</p>



<a name="244031456"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244031456" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244031456">(Jun 26 2021 at 19:53)</a>:</h4>
<p>perhaps I'm naive, but I don't see how that's possible. If I have an uninitialized  <code>x = [u8; A_ZILLION]</code>, then attempt to say <code>x[A_ZILLION-1] = 2</code>, then the system has to ensure that the address of <code>&amp;x[A_ZILLION-1]</code> is offset by exactly a zillion from <code>&amp;x</code>. it couldn't use those inner addresses for anything at all</p>



<a name="244031517"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244031517" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244031517">(Jun 26 2021 at 19:55)</a>:</h4>
<p>The kernel will reserve the address space but not back it by physical memory. touching a specific address will cause a page fault for that page which will then back it with memory and return to userspace as if it had always been there.</p>



<a name="244031541"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244031541" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244031541">(Jun 26 2021 at 19:56)</a>:</h4>
<p>okay, I'm mixing up my virtual address spaces with physical address space</p>



<a name="244031723"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244031723" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244031723">(Jun 26 2021 at 20:00)</a>:</h4>
<p>Then again, can it even be used to get memory like that or would it always blow the stack?</p>



<a name="244031826"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244031826" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244031826">(Jun 26 2021 at 20:03)</a>:</h4>
<p>also, is it even possible for that to be safe, in Rust terms?</p>



<a name="244032127"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244032127" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244032127">(Jun 26 2021 at 20:08)</a>:</h4>
<p>Maybe if you somehow remember which bits you have initialized and don't hand out references to the whole array. Using <code>Box::new_zeroed()</code> would be easier. That way it wouldn't have to write zeroes to your allocation and use calloc instead which gets you the same virtual memory optimization.</p>



<a name="244032138"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244032138" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244032138">(Jun 26 2021 at 20:09)</a>:</h4>
<p>But that's still unstable.</p>



<a name="244032270"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244032270" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244032270">(Jun 26 2021 at 20:12)</a>:</h4>
<p>Rust doesn't really place any constraints on the implementation of stack – it doesn't even need to be a single chunk of virtual memory.</p>



<a name="244032278"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244032278" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244032278">(Jun 26 2021 at 20:12)</a>:</h4>
<p>So depending on target and/or other particularities you may be able to allocate large structures on the stack. Very non-portable though.</p>



<a name="244032287"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244032287" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244032287">(Jun 26 2021 at 20:13)</a>:</h4>
<p><span class="user-mention silent" data-user-id="256342">bstrie</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244031826">said</a>:</p>
<blockquote>
<p>also, is it even possible for that to be safe, in Rust terms?</p>
</blockquote>
<p>WDYM by "that" precisely?</p>



<a name="244033122"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244033122" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244033122">(Jun 26 2021 at 20:35)</a>:</h4>
<p><span class="user-mention silent" data-user-id="123586">nagisa</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244032287">said</a>:</p>
<blockquote>
<p>WDYM by "that" precisely?</p>
</blockquote>
<p>Passing around an array whose elements may or may not be uninitialized. A piece of code that uses mem::uninitialized not in the standard sense of "I want to initialize this thing piece-by-piece, and then reach a point where I call it "initialized", and do normal operations on the now-initialized thing", but instead to say "I don't know <em>when</em> this array will be fully (or even partially) initialized, and it's possible that this array will <em>never</em> be fully initialized; I want the memory for each individual element of this array to be lazily reserved on-demand." If you're trying to do the latter, is it safe to, e.g., return that array from a function, or take a reference to it, or clone it, or call any stdlib function on it?</p>



<a name="244033267"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244033267" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244033267">(Jun 26 2021 at 20:39)</a>:</h4>
<p>So, not an authoritative answer here, but I want to say that passing by itself is <em>probably</em> okay as long as the uninit elements are not ever read. Alas clone and most stdlib functions do count as reading the elements, so the line is blurry?</p>



<a name="244034971"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244034971" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244034971">(Jun 26 2021 at 21:19)</a>:</h4>
<p>At the end of the day I think the broader question boils down to: does the API for mem::uninitialized actually include the guarantee that no memory is actually reserved, or does it just guarantee that you will receive an implementation-defined (possibly unspecified, possibly undefined) value? Because the latter interpretation of mem::uninitialized, while practically useless, is at least possible to specify, implement, and use. As it currently exists it would seem to be the height of absurdity for a theoretical Rust specification to attempt to specify the behavior of mem::uninitialized--we might imagine an exasperated author just writing "invoke this function in order to produce undefined behavior"--and it would be likewise absurd for any alternative implementation to be forced to implement it.</p>



<a name="244035715"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244035715" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244035715">(Jun 26 2021 at 21:40)</a>:</h4>
<p>It is definitely expected behavior on linux for <code>Box::new_uninit</code> and <code>Box::new_zeroed</code>. I'm less sure about <code>mem::uninitialized</code> or how one would use that in a meaningful way.</p>



<a name="244035985"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244035985" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244035985">(Jun 26 2021 at 21:47)</a>:</h4>
<p>mem::uninitialized is in core, so it surely doesn't use the heap, but otherwise it doesn't assure you of anything.</p>



<a name="244036103"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036103" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036103">(Jun 26 2021 at 21:51)</a>:</h4>
<p><span class="user-mention" data-user-id="224471">@Lokathor</span> I'm unclear, are you arguing that the stdlib has the latitude to consider such a change to the implementation of mem::uninitialized?</p>



<a name="244036152"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036152" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036152">(Jun 26 2021 at 21:52)</a>:</h4>
<p>absolutely it does</p>



<a name="244036241"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036241" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036241">(Jun 26 2021 at 21:55)</a>:</h4>
<p>It's UB anyway so we can choose to have the UB end up being "you get a zeroed value".</p>



<a name="244036320"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036320" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036320">(Jun 26 2021 at 21:57)</a>:</h4>
<p>I don't disagree, but I can already see people coming with complaints on how rust is not backwards compatible at all.</p>



<a name="244036465"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036465" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036465">(Jun 26 2021 at 22:01)</a>:</h4>
<p>Soundness fixes have always been am exception</p>
<p>and absolute performance has very rarely been assured. Some places will guarantee "this doesn't reallocate except in these conditions", but that is not the same as a perfect performance guarantee.</p>



<a name="244036580"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036580" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> inquisitivecrystal <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036580">(Jun 26 2021 at 22:05)</a>:</h4>
<p>UB isn't guarenteed to be backwards compatible. The one thing that's kind of unfortunate (in my very inexperienced opinion) is that we didn't used to be so clear about exactly <em>how</em> UB it was. That being said, it's been deprecated for ages now, so...</p>



<a name="244036635"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036635" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036635">(Jun 26 2021 at 22:07)</a>:</h4>
<p>I mean, the other alternative is to outright remove it, but I'm trying to be conservative in this proposal :P</p>



<a name="244036646"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036646" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036646">(Jun 26 2021 at 22:07)</a>:</h4>
<p>Too bad IIRC we can't remove functions from libstd based on the edition.</p>



<a name="244036650"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036650" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036650">(Jun 26 2021 at 22:08)</a>:</h4>
<p>this is the backcompat-friendly option, where the behavior changes slightly but no code stops compiling and there's no semantic runtime difference</p>



<a name="244036693"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036693" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036693">(Jun 26 2021 at 22:08)</a>:</h4>
<p><span class="user-mention" data-user-id="123586">@nagisa</span> <a href="https://github.com/rust-lang/rfcs/pull/3088">https://github.com/rust-lang/rfcs/pull/3088</a></p>



<a name="244036695"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036695" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> inquisitivecrystal <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036695">(Jun 26 2021 at 22:08)</a>:</h4>
<p>At what point would you be comfortable removing it? Or are you suggesting to not remove it at all?</p>



<a name="244036879"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036879" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> inquisitivecrystal <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036879">(Jun 26 2021 at 22:15)</a>:</h4>
<p>Oh, hmm. I read that PR and it says that currently nothing can be removed from <code>std</code> at all. I guess I'd always assumed that deprecated things could be removed after enough time had passed.</p>



<a name="244036930"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244036930" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244036930">(Jun 26 2021 at 22:16)</a>:</h4>
<p>I'm seeking to avoid the question of whether or not this should be removed, or when. My goal right now is to place mem::uninitialized on the same level as every other deprecated API, i.e., I want to take this function from "this is actively hazardous" to "this is merely discouraged".</p>



<a name="244037069"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244037069" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244037069">(Jun 26 2021 at 22:20)</a>:</h4>
<p><span class="user-mention silent" data-user-id="123586">nagisa</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244036320">said</a>:</p>
<blockquote>
<p>I don't disagree, but I can already see people coming with complaints on how rust is not backwards compatible at all.</p>
</blockquote>
<p>tbh, already mem::uninitialized has already been the biggest backwards compat issue in rust in practice IME. i have several old projects that no longer run because they call into a library that apparently does some UB with mem::uninitialized, but there's nothing i can do about it since they didn't get fixed for several versions, and have many breaking changes before they ultimately got fixed.</p>
<p>even just theoretically, i'd argue (and have before) the functions existence was a promise that there was a correct way to use it, and apparently the consensus since then is that there is not.</p>
<p>anyway, i guess that's all to say, that this function is already a disaster of rust's backwards compat story in many ways, i don't think this would meaningfully move the needle on it.</p>



<a name="244037145"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244037145" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244037145">(Jun 26 2021 at 22:23)</a>:</h4>
<p>Should the mem::uninitialized deprecation be changed into an forward compat lint even if there is no intention to ever remove it?</p>



<a name="244038538"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244038538" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244038538">(Jun 26 2021 at 23:00)</a>:</h4>
<p>well, it's effectively wrong to ever call the function ever, so linting against ot doesn't seem unreasonable, but using deprecated things is already linted against, isn't it?</p>



<a name="244038555"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244038555" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244038555">(Jun 26 2021 at 23:01)</a>:</h4>
<p>I think the main problem is in old code that's not being updated and is being used as a dependency with lints capped</p>



<a name="244038556"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244038556" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244038556">(Jun 26 2021 at 23:01)</a>:</h4>
<p>the future compatibility lint is only for things that will eventually be removed from all editions, so you wouldn't use it unless people had agreed to remove mem::uninitialized from std</p>



<a name="244038664"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244038664" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244038664">(Jun 26 2021 at 23:04)</a>:</h4>
<p><span class="user-mention silent" data-user-id="209168">Thom Chiovoloni</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244037069">said</a>:</p>
<blockquote>
<p>i have several old projects that no longer run because they call into a library that apparently does some UB with mem::uninitialized</p>
</blockquote>
<p>are these projects failing to run because of the mandatory panic on certain types (all types that contain uninhabited values), or are they failing to run because of some wild UB memory corruption? because if it's the latter, then this proposal would actually fix that.</p>



<a name="244038690"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244038690" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244038690">(Jun 26 2021 at 23:05)</a>:</h4>
<p>slightly aside: rust is so "stable" but we assume that all code is  being actively maintained at all times. I think the better fix is to change the implementation so that old code gets a fix applied without them having to update at all. i mean the long term ideal is that we eventually start to have libraries that we don't have to update, right?</p>



<a name="244038747"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244038747" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244038747">(Jun 26 2021 at 23:06)</a>:</h4>
<p>thus, make it just do a <code>zeroed</code> as bstrie is saying, rather than adjusting lints and hoping some devs sees a lint.</p>



<a name="244040336"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244040336" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244040336">(Jun 26 2021 at 23:44)</a>:</h4>
<p>FWIW, in theory you could ask the memory allocator for zeroed memory, and if it gets new pages from the OS it can assume they're zero.</p>



<a name="244040389"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244040389" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244040389">(Jun 26 2021 at 23:44)</a>:</h4>
<p>If they're new pages, rather than reused.</p>



<a name="244040524"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244040524" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244040524">(Jun 26 2021 at 23:49)</a>:</h4>
<p>vec already has that optimization</p>



<a name="244040578"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244040578" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244040578">(Jun 26 2021 at 23:50)</a>:</h4>
<p>for some std-owned types</p>



<a name="244041367"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244041367" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244041367">(Jun 27 2021 at 00:10)</a>:</h4>
<p>I don't think I'd want <code>mem::uninitialized()</code> to become <em>safe</em> -- that's even more of an invitation to use it for the invariant check, and if people want that we should make an actual function/trait for it -- but I'd certainly be open to potentially tweaking its implementation to reduce footguns for old code, given that it could update to <code>MaybeUninit</code> to recover the perf impact.</p>



<a name="244041373"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244041373" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244041373">(Jun 27 2021 at 00:10)</a>:</h4>
<p>Like the classic "write <code>DEADBEEF</code> into the first 4 bytes" or something.</p>



<a name="244042675"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244042675" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244042675">(Jun 27 2021 at 00:50)</a>:</h4>
<p>Well, the advantage of zeroed memory is that more types can be all 0s than can be most other sentinel bits. Though if the sentinel pattern were say <code>0x01</code> in all bytes that would probably be fine too. If libstd wasn't prebuilt all the time we could even have sentinel in debug and plain zeroed in release.</p>



<a name="244043738"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244043738" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244043738">(Jun 27 2021 at 01:28)</a>:</h4>
<blockquote>
<p>are these projects failing to run because of the mandatory panic on certain types (all types that contain uninhabited values)</p>
</blockquote>
<p>yes, it's this. I don't expect anything to fix it, but think it's quite unfortunate since that code for the most part worked (it was part of an outdated offsetof-alike, iirc — again, it wasn't my code, it was in a lib i used (glium, i think)), but running that code requires figuring out which version of rust it last ran on.</p>



<a name="244048128"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244048128" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244048128">(Jun 27 2021 at 03:52)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244042675">said</a>:</p>
<blockquote>
<p>Well, the advantage of zeroed memory is that more types can be all 0s than can be most other sentinel bits.</p>
</blockquote>
<p>Given <code>NonNull</code> and references and such, I'm less certain of that.  I guess it depends if you weight to enums or data structures.</p>



<a name="244048359"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244048359" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244048359">(Jun 27 2021 at 04:00)</a>:</h4>
<p>yeah if we wanted to always get it right no matter what we'd have to do some specialization steps</p>



<a name="244048367"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244048367" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244048367">(Jun 27 2021 at 04:01)</a>:</h4>
<p>zeroed memory has the special panic check already at least</p>



<a name="244050695"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244050695" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244050695">(Jun 27 2021 at 05:25)</a>:</h4>
<p><span class="user-mention silent" data-user-id="125270">scottmcm</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244041367">said</a>:</p>
<blockquote>
<p>I don't think I'd want <code>mem::uninitialized()</code> to become <em>safe</em></p>
</blockquote>
<p>What I'm proposing is not to remove the <code>unsafe</code> marker from this function, but merely to replace the implementation with something that is (arguably!) semantically equivalent and eliminates all existing memory safety risk--even at the cost of making this function effectively just an alias of mem::zeroed, which I'll argue is fine since 1) this function is inherently broken, and cannot possibly be used safely any other way, and 2) mem::MaybeUninit is a mature replacement for its original use case</p>



<a name="244050752"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244050752" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244050752">(Jun 27 2021 at 05:27)</a>:</h4>
<p>(and if there's some other solution other than mem::zeroed, that's fine too, I don't care about the exact replacement as much as I care about disarming the safety risk and making it actually possible to specify and implement)</p>



<a name="244050960"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244050960" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244050960">(Jun 27 2021 at 05:34)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244048367">said</a>:</p>
<blockquote>
<p>zeroed memory has the special panic check already at least</p>
</blockquote>
<p>both mem::zeroed and mem::uninitialized have panic checks; mem::zeroed panics if a type must not be zeroes, whereas mem::uninitialized panics if a type has any uninhabited values at all. in theory, replacing the innards of mem::uninitialized with mem::zeroed could allow mem::uninitialized's current panic check to be loosened, which might help <span class="user-mention" data-user-id="209168">@Thom Chiovoloni</span>'s use case</p>



<a name="244051322"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244051322" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244051322">(Jun 27 2021 at 05:48)</a>:</h4>
<p><span class="user-mention silent" data-user-id="256342">bstrie</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244030355">said</a>:</p>
<blockquote>
<p>it occurs to me that this function could be made safe</p>
</blockquote>
<p>^ Ah, when you said this that to me meant "remove the <code>unsafe</code>" marker.</p>



<a name="244060240"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244060240" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244060240">(Jun 27 2021 at 10:21)</a>:</h4>
<p><span class="user-mention silent" data-user-id="123586">nagisa</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244036646">said</a>:</p>
<blockquote>
<p>Too bad IIRC we can't remove functions from libstd based on the edition.</p>
</blockquote>
<p>we could. it's not too hard to implement. but in practice just making this specific deprecation a (hard) error in the new edition is probably easier and a better idea. thatt way, the documentation is still visible etc.</p>



<a name="244060242"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244060242" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244060242">(Jun 27 2021 at 10:21)</a>:</h4>
<p><span class="user-mention silent" data-user-id="133247">bjorn3</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244037145">said</a>:</p>
<blockquote>
<p>Should the mem::uninitialized deprecation be changed into an forward compat lint even if there is no intention to ever remove it?</p>
</blockquote>
<p>yeah, maybe</p>



<a name="244060255"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244060255" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244060255">(Jun 27 2021 at 10:21)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244038555">said</a>:</p>
<blockquote>
<p>I think the main problem is in old code that's not being updated and is being used as a dependency with lints capped</p>
</blockquote>
<p>that'd be fixed by making it a future incompatibility lint. cargo does show those for dependencies</p>



<a name="244060326"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244060326" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244060326">(Jun 27 2021 at 10:23)</a>:</h4>
<p>and with <span class="user-mention" data-user-id="224872">@rylev</span>'s recent change, we could add a <code>FutureIncompatibilityReason::Unsound</code> or something with a more specific message than just "this will break in a future release".</p>



<a name="244060333"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244060333" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244060333">(Jun 27 2021 at 10:23)</a>:</h4>
<p>"this is already unsound, and will break in more unpredictable ways in the future"</p>



<a name="244060458"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244060458" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244060458">(Jun 27 2021 at 10:26)</a>:</h4>
<p>or insert some kind of empty asm block that can write to the buffer. then llvm can't know whether the buffer was written to or not and no longer sees it as undef</p>



<a name="244060730"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244060730" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244060730">(Jun 27 2021 at 10:35)</a>:</h4>
<p>that 'works' because it takes the address of the data, forcing it to be in memory instead of in a register.</p>



<a name="244062212"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244062212" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244062212">(Jun 27 2021 at 11:17)</a>:</h4>
<p>the proper way seems to be llvm's <code>freeze</code> instruction: <a href="https://llvm.org/docs/LangRef.html#freeze-instruction">https://llvm.org/docs/LangRef.html#freeze-instruction</a></p>



<a name="244064566"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244064566" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244064566">(Jun 27 2021 at 12:21)</a>:</h4>
<p>apparently the OS makes that whole thing a lot harder, because it might swap pages away if you haven't written to them, causing multiple reads to actually return different results: <a href="https://internals.rust-lang.org/t/what-the-hardware-does-is-not-what-your-program-does-uninitialized-memory/10561/27?u=ralfjung">see this comment</a></p>



<a name="244064731"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244064731" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244064731">(Jun 27 2021 at 12:25)</a>:</h4>
<p>Afaik the kernel always gives you zeroed pages (except on some embedded systems). It's the allocator's doing if you're getting back reused pages.</p>



<a name="244070512"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244070512" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244070512">(Jun 27 2021 at 14:59)</a>:</h4>
<p>sure, with 'OS' i mean the combination of kernel and libc etc.</p>



<a name="244070648"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244070648" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244070648">(Jun 27 2021 at 15:02)</a>:</h4>
<p>Is that relevant to mem::uninitialized though? What would tell the allocator to free memory under our nose while we still anything referring to the span of memory?</p>



<a name="244070713"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244070713" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244070713">(Jun 27 2021 at 15:04)</a>:</h4>
<p>Worth noting also that stack is also memory and it is not generally zeroed.</p>



<a name="244070729"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244070729" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244070729">(Jun 27 2021 at 15:05)</a>:</h4>
<p>I'm surprised though that reads from allocated but not written-to memory can produce different results on different reads.</p>



<a name="244070861"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244070861" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244070861">(Jun 27 2021 at 15:08)</a>:</h4>
<p>Ah. MADV_FREE is a delayed action and only undone by writes, not reads. So yeah, if the allocator recycles memory that way it's true that your reads will be non-deterministic</p>



<a name="244070963"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244070963" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244070963">(Jun 27 2021 at 15:10)</a>:</h4>
<p>yeah</p>



<a name="244073190"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244073190" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244073190">(Jun 27 2021 at 16:07)</a>:</h4>
<p><span class="user-mention silent" data-user-id="310399">Mara</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244060242">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="133247">bjorn3</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244037145">said</a>:</p>
<blockquote>
<p>Should the mem::uninitialized deprecation be changed into an forward compat lint even if there is no intention to ever remove it?</p>
</blockquote>
<p>yeah, maybe</p>
</blockquote>
<p>Recent conversations lead me to believe that people want to tighten up the meaning of the future compat lint, rather than dilute it. <a href="#narrow/stream/268952-edition-2021/topic/pat_2021.20on.202018/near/243697632">https://rust-lang.zulipchat.com/#narrow/stream/268952-edition-2021/topic/pat_2021.20on.202018/near/243697632</a></p>
<p>That said, it could be made future-incompat, with an intention to remove (via the soundness exception to the stability policy), but that removal could very well happen ten years from now.</p>



<a name="244073354"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244073354" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244073354">(Jun 27 2021 at 16:10)</a>:</h4>
<p>I don't think it's clear that there are <em>no</em> sound uses, so I'm not convinced that removing it is ok.</p>



<a name="244073566"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244073566" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244073566">(Jun 27 2021 at 16:16)</a>:</h4>
<p><span class="user-mention" data-user-id="125270">@scottmcm</span> that's reasonable (and to reiterate, the original proposal was not to remove the function), but as an exercise, all unsafe functions in the stdlib are supposed to be documented with a "Safety" section describing the invariants that the caller needs to uphold. mem::uninitialized doesn't have such a section today; what would you suggest that this section would say?</p>



<a name="244073629"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244073629" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244073629">(Jun 27 2021 at 16:18)</a>:</h4>
<p>I'd start with "UB if T has any validity invariants", though that's not sufficient.</p>



<a name="244073916"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244073916" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244073916">(Jun 27 2021 at 16:25)</a>:</h4>
<p>I ask because the current guts of mem::uninitialized is just <code>MaybeUninit::uninit().assume_init()</code>, and if we look at the Safety section of <code>assume_init()</code>, it reads: "It is up to the caller to guarantee that the MaybeUninit&lt;T&gt; really is in an initialized state. Calling this when the content is not yet fully initialized causes immediate undefined behavior." The type level documentation also contains the following example:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="kd">let</span><span class="w"> </span><span class="n">x</span>: <span class="kt">i32</span> <span class="o">=</span><span class="w"> </span><span class="k">unsafe</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="n">MaybeUninit</span>::<span class="n">uninit</span><span class="p">().</span><span class="n">assume_init</span><span class="p">()</span><span class="w"> </span><span class="p">};</span><span class="w"> </span><span class="c1">// undefined behavior! ⚠️</span>
</code></pre></div>
<p>So it's possible that the MaybeUninit docs are just being overly conservative, but as written they imply that <em>any</em> call to mem::uninitialized is immediate and unavoidable UB</p>



<a name="244073922"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244073922" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244073922">(Jun 27 2021 at 16:25)</a>:</h4>
<p><span class="user-mention silent" data-user-id="256342">bstrie</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244073190">said</a>:</p>
<blockquote>
<p>Recent conversations lead me to believe that people want to tighten up the meaning of the future compat lint, rather than dilute it.</p>
</blockquote>
<p>Huh. This isn't about 'tightening' or 'diluting'. just about being correct. in that that case you linked i was arguing against having edition compat lints be future incompat lints because these aren't things that are or will be broken without manual action.</p>



<a name="244074221"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244074221" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244074221">(Jun 27 2021 at 16:32)</a>:</h4>
<p><span class="user-mention silent" data-user-id="256342">bstrie</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244073916">said</a>:</p>
<blockquote>
<p>So it's possible that the MaybeUninit docs are just being overly conservative, but as written they imply that <em>any</em> call to mem::uninitialized is immediate and unavoidable UB</p>
</blockquote>
<p>Well, the docs already say:</p>
<blockquote>
<p>The reason for deprecation is that the function basically cannot be used correctly</p>
</blockquote>



<a name="244074230"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244074230" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244074230">(Jun 27 2021 at 16:33)</a>:</h4>
<p>Yes, I'm just quoting the MaybeUninit docs in response to the idea that there might be sound uses of this function</p>



<a name="244074617"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244074617" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244074617">(Jun 27 2021 at 16:42)</a>:</h4>
<p>And to reiterate, I believe this function could be made sound, if the call to <code>MaybeUninit::uninit.assume_init()</code> were replaced by <code>zeroed()</code>. It would also be made pointless, yes, but still better than the current state, in that the resulting Rust program would at least be valid.</p>



<a name="244076966"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244076966" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244076966">(Jun 27 2021 at 17:43)</a>:</h4>
<blockquote>
<p>So it's possible that the MaybeUninit docs are just being overly conservative, but as written they imply that any call to mem::uninitialized is immediate and unavoidable UB</p>
</blockquote>
<p>Technically speaking you <em>can</em> legally create a MaybeUninit value using <code>MaybeUninit::uninit().assume_init()</code>, or an array of such values.</p>



<a name="244086392"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/244086392" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#244086392">(Jun 27 2021 at 21:41)</a>:</h4>
<p><span class="user-mention silent" data-user-id="310399">Mara</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244060255">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="224471">Lokathor</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244038555">said</a>:</p>
<blockquote>
<p>I think the main problem is in old code that's not being updated and is being used as a dependency with lints capped</p>
</blockquote>
<p>that'd be fixed by making it a future incompatibility lint. cargo does show those for dependencies</p>
</blockquote>
<p>The downside is that just the lint doesn't actually fix the code. Someone still has to go actually make a change and publish a new version.</p>
<p>If it was a lint + it gives you a zeroed (which is enough in many many cases) then that would be better.</p>



<a name="245576728"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245576728" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245576728">(Jul 10 2021 at 23:12)</a>:</h4>
<blockquote>
<p>s it currently exists it would seem to be the height of absurdity for a theoretical Rust specification to attempt to specify the behavior of mem::uninitialized--we might imagine an exasperated author just writing "invoke this function in order to produce undefined behavior"</p>
</blockquote>
<p>it's not quite <em>that</em> bad. ;) the function is actually specified pretty easily: <code>mem::uninitialized::&lt;T&gt;</code> returns the value obtained by interpreting <code>size_of::&lt;T&gt;()</code> many uninit bytes at type <code>T</code>. (likewise, <code>mem::zeroed::&lt;T&gt;</code> returns the value obtained by interpreting <code>size_of::&lt;T&gt;()</code> many 0x00 bytes at type <code>T</code>.)<br>
it's just that for the vast majority of types, "<code>size_of::&lt;T&gt;()</code> many uninit bytes" does not represent <em>any</em> value, and hence we have UB.</p>
<p>(also FWIW, "invoke this function in order to produce undefined behavior" is actually a very useful function, it's called <code>unreachable_unchecked</code>)</p>



<a name="245576811"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245576811" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245576811">(Jul 10 2021 at 23:15)</a>:</h4>
<blockquote>
<p>eliminates all existing memory safety risk</p>
</blockquote>
<p>that's impossible... <code>mem::zeroed</code> is still <code>unsafe</code>, after all<br>
later you say you think the function can be made 'sound', but soundness is a property of a <em>safe</em> API, so I don't know what you mean by this.</p>



<a name="245576863"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245576863" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245576863">(Jul 10 2021 at 23:16)</a>:</h4>
<p><span class="user-mention silent" data-user-id="330154">The 8472</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/244070648">said</a>:</p>
<blockquote>
<p>Is that relevant to mem::uninitialized though? What would tell the allocator to free memory under our nose while we still anything referring to the span of memory?</p>
</blockquote>
<p>what the allocator and hardware do is <a href="https://www.ralfj.de/blog/2019/07/14/uninit.html">almost entirely irrelevant</a> for the purpose of this discussion</p>



<a name="245577050"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245577050" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245577050">(Jul 10 2021 at 23:22)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/245576811">said</a>:</p>
<blockquote>
<blockquote>
<p>eliminates all existing memory safety risk</p>
</blockquote>
<p>that's impossible... <code>mem::zeroed</code> is still <code>unsafe</code>, after all</p>
</blockquote>
<p>this is something I've been meaning to ask... I don't see how <code>zeroed</code> is unsafe these days. Back in 2018 you added an assertion that guarantees a panic if it is ever used with a type that can' t be zero, and I'm not aware of any other safety invariants</p>



<a name="245577211"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245577211" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245577211">(Jul 10 2021 at 23:27)</a>:</h4>
<p>Arbitrary user-provided types can have arbitrary safety invariants. And the non_zero check is only a "here's us being nice to you because you wrote unreachable_unchecked() by accident", AFAIK (It's not actually guaranteed).</p>



<a name="245577405"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245577405" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245577405">(Jul 10 2021 at 23:32)</a>:</h4>
<p>Interesting, I was putting too much faith in the zeroed check. Regardless, I don't think that changes anything about the PR, as the point is that <code>zeroed</code> can be used safely, while <code>unintialized</code> (currently) can't</p>



<a name="245577432"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245577432" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Pratt <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245577432">(Jul 10 2021 at 23:33)</a>:</h4>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/245577211">said</a>:</p>
<blockquote>
<p>Arbitrary user-provided types can have arbitrary safety invariants. And the non_zero check is only a "here's us being nice to you because you wrote unreachable_unchecked() by accident", AFAIK (It's not actually guaranteed).</p>
</blockquote>
<p>That's the call to <code>unreachable_unchecked()</code> that's the issue then, not <code>mem::zeroed()</code>. If <code>mem::zeroed()</code> always results in a valid value (and apparently there's a check for this), then it's memory safe.</p>



<a name="245577486"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245577486" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245577486">(Jul 10 2021 at 23:34)</a>:</h4>
<p><span class="user-mention" data-user-id="245610">@Jacob Pratt</span> apparently it's not the case that the zeroed check catches <em>all</em> cases where a type can't be zero, see <a href="https://github.com/rust-lang/rust/issues/66151">https://github.com/rust-lang/rust/issues/66151</a></p>



<a name="245577565"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245577565" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245577565">(Jul 10 2021 at 23:37)</a>:</h4>
<p><span class="user-mention silent" data-user-id="245610">Jacob Pratt</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/245577432">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="257758">Connor Horman</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/245577211">said</a>:</p>
<blockquote>
<p>Arbitrary user-provided types can have arbitrary safety invariants. And the non_zero check is only a "here's us being nice to you because you wrote unreachable_unchecked() by accident", AFAIK (It's not actually guaranteed).</p>
</blockquote>
<p>That's the call to <code>unreachable_unchecked()</code> that's the issue then, not <code>mem::zeroed()</code>. If <code>mem::zeroed()</code> always results in a valid value (and apparently there's a check for this), then it's memory safe.</p>
</blockquote>
<p>I was comparing <code>mem::zeroed::&lt;NonZeroU8&gt;()</code> and the like to <code>unreachable_unchecked()</code> because they are semantically identical. Rustc just decided to panic instead when the person may have unintentionally written a function call that is identical to <code>unreachable_unchecked()</code>. Additionally, it's not memory safe to produce an zeroed bitpattern for any general type, even if it's not an invalid value, so whether or not it's stabily guaranteed to panic for a type that cannot be zero-initialized, it still cannot be safe.</p>



<a name="245577621"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245577621" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245577621">(Jul 10 2021 at 23:39)</a>:</h4>
<p>User defined types can have any rules it wants, even "cannot be created on a Tuesday". In that case, if you created such a type with <code>mem::zeroed()</code> on a Tuesday, you've violated the invariant of that type, even if, according to the rust language, such a value is valid.</p>



<a name="245577985"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245577985" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245577985">(Jul 10 2021 at 23:50)</a>:</h4>
<p>hm, originally I was deliberately overlooking user-defined types as I was only considering types with invalid values (which AFAIK only the stdlib has the ability to define, and should in theory be able to perfectly detect), but yes, it certainly is true that there are plenty of other invariants that you could violate this way</p>



<a name="245577995"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245577995" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245577995">(Jul 10 2021 at 23:51)</a>:</h4>
<p>still, the goal of this is not and has never been to remove the <code>unsafe</code> from these functions, only to make <code>uninitialized</code> not be an immediate footgun</p>



<a name="245585426"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245585426" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245585426">(Jul 11 2021 at 03:31)</a>:</h4>
<p>is it possible this actually makes things <em>more</em> (rather than less) likely to cause problems with LLVM? C++ code has uninitialized values all the time, it's not really UB until you initialize it as UB, which using mem::zeroed() would do</p>



<a name="245603374"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245603374" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245603374">(Jul 11 2021 at 11:53)</a>:</h4>
<p><span class="user-mention silent" data-user-id="256342">bstrie</span> <a href="#narrow/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized/near/245577995">said</a>:</p>
<blockquote>
<p>still, the goal of this is not and has never been to remove the <code>unsafe</code> from these functions, only to make <code>uninitialized</code> not be an immediate footgun</p>
</blockquote>
<p>yes that makes sense, but you claiming that this would make things "safe" muddied the waters a lot^^</p>



<a name="245603432"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245603432" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245603432">(Jul 11 2021 at 11:54)</a>:</h4>
<p>it seems like we now agree that <code>zeroed</code> even with the best panic check we could write (which we dont currently do) is still very much an <code>unsafe</code> function? The one-sentence summary is that the best rustc can do is check <a href="https://www.ralfj.de/blog/2018/08/22/two-kinds-of-invariants.html">the validity invariant, but it cannot know about the safety invariant</a>.</p>



<a name="245603449"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245603449" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245603449">(Jul 11 2021 at 11:55)</a>:</h4>
<p>The <a href="https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#safety"><code>assume_init</code> docs</a> explicitly call this out, though maybe not with the best example. Do we need to also be more explicit about this in the <code>uninitialized</code> and <code>zeroed</code> docs?</p>



<a name="245622560"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245622560" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245622560">(Jul 11 2021 at 19:22)</a>:</h4>
<p>yes, I'm guilty of being too informal here, and I need to reread that blog post because I'm sure I've also used "safety invariant" when I might have meant "validity invariant" :P</p>



<a name="245624212"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245624212" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245624212">(Jul 11 2021 at 20:09)</a>:</h4>
<p>I do think more documentation would be useful here, though I'm not sure if the unsafe code guidelines WG has a better place to put it than in the MaybeUninit docs. For example, I found it useful to understand that the only types that are allowed to be uninitialized are ZSTs, (maybe) unions with a ZST field, and arrays (and tuples?) of the same. Knowing what <em>is</em> allowed to be uninitialized helps to alleviate the surprise of simply being told that i32 can't be uninitialized.</p>



<a name="245786971"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/245786971" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#245786971">(Jul 13 2021 at 07:20)</a>:</h4>
<p><span class="user-mention" data-user-id="209168">@Thom Chiovoloni</span> I'd love for you to share your issues at <a href="https://github.com/rust-lang/rust/issues/66151">https://github.com/rust-lang/rust/issues/66151</a>. A discussion could be had about taming down that panic -- I honestly expected such a discussion much earlier than this and am rather surprised it has not happened yet.</p>



<a name="247826727"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/disarming%20mem%3A%3Auninitialized/near/247826727" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/disarming.20mem.3A.3Auninitialized.html#247826727">(Jul 31 2021 at 22:27)</a>:</h4>
<p>I've closed the original PR, but opened a new issue for "initialized" <code>mem::uninitialized</code> with the idea that Rust could leverage its understanding of niches to produce a valid initialized value for any given type: <a href="https://github.com/rust-lang/rust/issues/87675">https://github.com/rust-lang/rust/issues/87675</a></p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>